1. Field of the Invention
The present invention relates to a method and a device for transmitting a data stream, a computer program which causes a computer or processor to carry out the transmission method when it is executed, and an information storage means storing the program.
The invention lies in the technical field of communication networks.
The present invention finds a particular application in the use of communication tunnels for the creation of virtual private networks via the Internet network.
2. Description of the Related Art
The technology of VPN (for “Virtual Private Network”) networks offers a valuable solution for communicating transparently in real time and continuously, in a secure manner between individuals sharing one centre of interest while using the Internet network infrastructure which is not very secure but cheap.
For communicating transparently and dispensing with addresses that cannot be routed, VPN networks use a particular encapsulation (called “tunnelling”) using a communication tunnel. This operation consists in encapsulating a layer A protocol (called the onboard or transported or passenger protocol) in a layer B protocol (called the transport or carrying protocol) by virtue of an encapsulation protocol C. Therefore, the transport protocol B treats the onboard protocol A as payload data.
FIG. 3, described in detail below, shows an example of packet encapsulation in a layer-2 VPN network. The onboard protocol A is a protocol of the 2nd layer (“layer-2”) of the OSI model. The term layer-2 tunnel is also used.
Such communication tunnels are used to interconnect two Local Area Network (“LANs”) in order to create a virtual LAN network comprising the original two LANs.
An illustration of a VPN network configuration based on a tunnelling technology is illustrated in FIG. 1 (described in detail below). The tunnel is established between two tunnel end points (“TEPs”), and each packet (also called a frame) originating from a first LAN 103 is sent to a second LAN 104 after having been encapsulated by the tunnel end point 101 situated on the first LAN 103; the tunnel end point 102 on the second LAN 104 receives the packet via the tunnel, decapsulates the packet and sends it to the second LAN 104. From the point of view of the pieces of equipment 108-113 connected to each of the first and second LANs, these pieces are virtually connected to one and the same LAN. In this example, the tunnel end points 101 and 102 are not incorporated into the gateways 105 and 106.
Patent application publication EP 2 020 799 describes a VPN network comprising several carriers, each of these carriers using a distinct transport protocol. In the present description, this type of tunnel will be called a multi-transport tunnel. Each tunnel end point then has a set of carriers with distinct characteristics. In order to transmit data from one LAN to the other LAN, it is necessary to adapt the transmission to the application needs and to the changes in transmission conditions on the Internet network. EP 2 020 799 describes a tunnel preferably consisting of a TCP (“Transmission Control Protocol”) carrier and a UDP (“User Datagram Protocol”) carrier. The TCP protocol is a transmission protocol with Automatic Repeat Request (“ARQ”) which is based on congestion and retransmission control mechanisms and thereby ensures the delivery of each packet to the destination. The UDP protocol is a protocol that is much simpler to use and faster, which does not take account of the order of the frames and supports no acknowledgement.
The UDP protocol then allows delivery of the data with a controlled latency, but with no guarantee with respect to data loss. In a tunnel, the UDP carrier is therefore used to convey data (passenger stream) with a high time constraint, such as for example audiovisual data. These audiovisual data are for example transmitted over a LAN according to the RTP (“Real-Time Transport Protocol”, as defined by the RFC-3550 standard) protocol. Such data cannot be transmitted via the TCP carrier of the tunnel because, in the event of a high error rate on the Internet network, the TCP carrier would generate many packet retransmissions in order to ensure the delivery of the data to the other tunnel end point. Such a behaviour is catastrophic for the end-to-end latency of the transported RTP stream. In addition, it should be noted that the flow control and the congestion control mechanisms used by the TCP protocol cause, according to the variation in network load, sharp variations in the data transmission rate.
Controlling the end-to-end transmission latency, while remaining robust with respect to data loss, has a very significant influence on the Quality of Experience (“QoE”) perceived by the user. Specifically, the slightest interruption in the transmission of the stream (that is to say a loss on the UDP carrier of the tunnel, a delay of the TCP carrier leading to obsolescence of the transported data) results in a degradation of the passenger stream. This results, for example, at the user level, in a break in the music clip listened to or in the video displayed.
There is no satisfactory transport method suitable for real time multimedia applications (“streaming”) making it possible to maintain the quality (QoE) perceived by the user despite the variations in transmission conditions in the context of using VPN networks.
The RFC-2198 standard (“RTP Payload for Redundant Audio Data”) proposes to insert into an RTP stream redundant copies of audio data that are present in this RTP stream, so that the receiver of the stream can correct the disruptions associated with losses caused during the transport of the RTP stream. The RFC-2198 standard therefore proposes to apply an FEC (for “Forward Error Correction”) mechanism, that is to say an error-correcting code (or parity code), in order to combat packet losses during transmission. Therefore, each RTP packet contains an item of audio data for a given time slot, and a copy (more compressed) of the audio data of a preceding time slot. This allows the approximate recomposition of the audio samples lost based on the decoding of the next packet. However, this solution creates a large overoccupation (“overhead”) of the bandwidth in order to transport the duplicate data; and is therefore more suitable for WLAN (“Wireless Local Area Network”) environments that are subjected to data losses than for WAN (“Wide Area Network”) environments where the nondelivery of a packet results from congestion on the transmission path. Specifically, in WAN environments, such a solution may make congestion phenomena encountered on the transmission path even worse.
Redundancy of the information only aggravates the congestion phenomenon on the global WAN network where the bandwidth is limited.